home *** CD-ROM | disk | FTP | other *** search
/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Telecommunications / Term Programs / Emacs Folder / README < prev   
Encoding:
Text File  |  1987-05-28  |  7.9 KB  |  157 lines  |  [TEXT/Earl]

  1. Communication from Earle Horton to Dave Burnard, May 8, 1987
  2.  
  3. Dave,
  4.  
  5.      Here is microemacs 3.8M, or whatever you want to call it.  It
  6. still has some minor bugs which I can't nail down, but it is
  7. essentially complete and functional.  Major changes I have made
  8. are inclusion of Lawrence's 3.8b sources, support of window
  9. resizing and zoom boxes, and support for draft-quality printing on
  10. a serial device.  It should be possible to compile this using MPW
  11. with relatively little effort.  The use of the proper #include
  12. files is an issue which I ignored, since I do not have MPW, but I
  13. have tried to be considerate of differences which I could see in
  14. your source files.  Wherever I have noticed it, I have passed
  15. Points to the toolbox routines using a "Passpt" macro which should
  16. produce the correct parameter for either LSC or MPW.  You should
  17. NOT use "stdio.h" supplied with MPW, as I use parameter block
  18. routines for disk IO exclusively.  
  19.  
  20. You should rather use the include file on this disk.  I have
  21. changed the order of #include files from <stdio> first to
  22. "estruct.h" first.  This is because "estruct.h" defines TRUE and
  23. FALSE, which are redefined in FileMgr.h with Lightspeed C.  The
  24. library file stdio.lib contains some utility functions I wrote
  25. using MDS, I presume you can assemble and link the source to the C
  26. routines using the MPW assembler.  Note that globals are shared
  27. between my assembler routines and C.  To be honest, the only
  28. reason to call the #include file stdio.h is so I could have
  29. something to #include, and so could avoid another set of #defines
  30. in all the source files. 
  31.  
  32.      I have made some changes to TTY_Windows.c to support resizing
  33. the microemacs window and zoom boxes, and have tried to improve
  34. handling of update events.  (There is a lot of apparent black
  35. magic involved in handling update events properly.) I have also
  36. cleaned things up a bit, to the point where Points are accessed
  37. somewhat more consistently.  I split the code into two files,
  38. because I got tired of memory errors when compiling the program on
  39. my 512k.  I also put the NewTTY_Window() function in a different
  40. segment, so it could be purged if memory gets tight.  A bug that
  41. exists at this point in the display code is that inverse video
  42. gets "erased" when another window is brought in front of the mode
  43. line.  I could fix it by using parts of my own display code, but I
  44. don't feel like it.  In my original port, I handled inverse video
  45. by using InvertRect(), which also works with 64k ROMS.  When I did
  46. this, I never had that problem. 
  47.  
  48.      There are two new fields in the "term" structure in 3.8
  49. (among others).  For the width and height there are fields for the
  50. number of maximum and current rows and columns.  A !major! bug in
  51. 3.8b, which I have fixed, is that during initialization only
  52. enough memory was allocated for the current number of rows and
  53. columns.  This resulted in a window enlargement causing a system
  54. crash every time.  I didn't annotate this in the source code, I
  55. just fixed it.  There is a bug in your single character output
  56. routine, which caused output of '\b' to not produce the desired
  57. effect.  I changed some routines in input.c to just put out a
  58. '\177' and that fixed that. 
  59.  
  60.      The emacs window is sized at initialization time now, based
  61. on the values of qd.screenBits.bounds (just screenBits.bounds to
  62. LSC).  The maximum size is set to 50% wider than the screen width,
  63. and the number of columns in the "term" data structure is set
  64. accordingly.  You may want to try the following experiment: Drag
  65. the window to the left by approximately one half of the screen
  66. width.  Resize it to cover the screen.  Now hit the TrackBox. 
  67. This could be useful when C programs get indented too far. 
  68.  
  69. There are RMaker (yes, some people still use RMaker) sources for
  70. the resources I have used.  My printing code uses a resource of
  71. type 'Pcon', but it makes its own, so don't bother with putting in
  72. a 'Pcon', you don't need to.  Here is its structure below.  The
  73. first three fields are determined by what the user inputs to a
  74. ModalDialog box, the last three are constant, but may be altered
  75. using ResEdit. 
  76.  
  77. typedef struct{
  78.     int    pport;
  79.     int    pbaud;
  80.     int    pterm;
  81.     int    pagelength;        /* default, 55 */
  82.     int    margin;            /* left only, default 8 */
  83.     int    tabstops;        /* default 8 */
  84. } pconfig,*Pcfg,**Pfg;
  85.  
  86. Pagelength is the number of lines between top and bottom margins,
  87. which are fixed, but a user can change it with ResEdit.  Margin is
  88. left only.  Right margin is controlled by window width (a clumsy
  89. maneuver, but effective).  This is primitive code, designed for
  90. one purpose only, to print source code in draft mode on my Tandy
  91. DMP 110.  I have included enough options so that it should work
  92. with most ordinary serial printers, however.  It is also possible
  93. to do some clumsy formatting and to access a printer's native
  94. fonts by embedded control codes.  All characters which are in a
  95. document, except tabs, are sent raw to the printer. 
  96.     
  97. I have included a facility for supporting different printer types. 
  98. Microemacs formats all printed text into strings, with "margin"
  99. spaces on the left and tabs expanded to eight.  A printer setup
  100. dialog box prompts for baud rate, port, and "Line Terminator". 
  101. Line Terminator may be any one of CR, LF, CRLF, and "User
  102. Special".  If User Special is chosen, then the program looks for a
  103. resource of type 'ePrc' and ID 777 on the disk.  This stands for
  104. "emacs Printer control" by the way.  If this resource is found,
  105. then emacs sets up a Parameter block (ParamBlockRec) with the
  106. proper RefNum for the chosen serial port in it.  An opcode is put
  107. in d0, the resource is loaded, and the program calls it as a
  108. function.  There are four opcodes, one of which will be in d0 when
  109. the resource is called.  The meanings are, briefly:
  110.  
  111.     0: Initialize the printer 
  112.     1: Print out the line contained in ioBuffer(a0), 
  113.        whose length is in ioReqCount(a0).  Terminate
  114.        the line properly for the printer.
  115.         2: Do whatever is proper for the end of the page.
  116.         3: Do whatever is proper for the beginning of the page. 
  117.  
  118. The ePrc resource should have an entry point at the top, end in an
  119. RTS, and gets no storage, other than what it allocates as a stack
  120. frame.  However, the ioMisc field of the parameter block, unused
  121. by the device driver routines, points to a longword with nothing
  122. in it.  Since I am not sure precisely what the device driver does
  123. with this field, the printer command routine should save it in its
  124. stack frame, and restore it before returning, if it uses it. 
  125. Suggested uses are, call NewPtr, get a pointer to some storage,
  126. call NewHandle, get a handle to a whole block! 
  127.  
  128. The longword pointed to by the ioMisc field is an application
  129. global, which I use for no other purpose, so the printer command
  130. routine can "remember" things in a properly setup block if it
  131. wants.  The routine can have a0, a1, d0, and d1, without restoring
  132. them.  All other registers should be restored upon return.  Upon
  133. entry, a0 points to the io Parameter block, and d0 contains the
  134. (word) opcode as described above.  I have, naturally, included an
  135. example, written in MDS, which shows exactly how to write a
  136. printer command resource.  Note that if "User Special" is chosen,
  137. then ALL character output to the printer is actually done by the
  138. user's routine, so considerable freedom is allowed in what it can
  139. do. 
  140.  
  141. With Lightspeed C, these sources need to get linked to "MacTraps",
  142. "strings", and my "stdio" library.  I have made some minor changes
  143. to the regular microemacs sources to avoid linking in "sprintf",
  144. which yields a great savings in code.  Not using the regular
  145. "stdio" supplied with LSC was an even bigger savings in code size. 
  146. People without hard disks (me) appreciate touches like this.  I
  147. apologize for the lack of a Makefile, but such a thing is not
  148. needed for Lightspeed, so I just didn't get around to writing one. 
  149.  
  150. Anyway, the program is basically functional, and I have done all
  151. the work I can on it for a while.  Feel free to inspect, post,
  152. alter, or improve the code in any way that time permits you. 
  153. Thanks for everything. 
  154.  
  155. Earle
  156.  
  157.